The EDB Postgres Advanced Server must reveal detailed error messages only to the ISSO, ISSM, SA, and DBA.

Overview

Finding ID	Version	Rule ID	IA Controls	Severity
V-259267	EPAS-00-006600	SV-259267r938854_rule		Medium

Description
If the DBMS provides too much information in error logs and administrative messages to the screen, this could lead to compromise. The structure and content of error messages need to be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements. Some default DBMS error messages can contain information that could aid an attacker in, among other things, identifying the database type, host address, or state of the database. Custom errors may contain sensitive customer information. It is important that detailed error messages be visible only to those who are authorized to view them; that general users receive only generalized acknowledgment that errors have occurred; and that these generalized messages appear only when relevant to the user's task. For example, a message along the lines of, "An error has occurred. Unable to save your changes. If this problem persists, contact the help desk" would be relevant. A message such as "Warning: your transaction generated a large number of page splits" would likely not be relevant. Administrative users authorized to review detailed error messages typically are the ISSO, ISSM, SA, and DBA. Other individuals or roles may be specified according to organization-specific needs, with appropriate approval. This calls for inspection of application source code, which will require collaboration with the application developers. It is recognized that in many cases, the database administrator (DBA) is organizationally separate from the application developers, and may have limited, if any, access to source code. Nevertheless, protections of this type are so important to the secure operation of databases that they must not be ignored. At a minimum, the DBA must attempt to obtain assurances from the development organization that this issue has been addressed, and must document what has been discovered.

Description

If the DBMS provides too much information in error logs and administrative messages to the screen, this could lead to compromise. The structure and content of error messages need to be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements. Some default DBMS error messages can contain information that could aid an attacker in, among other things, identifying the database type, host address, or state of the database. Custom errors may contain sensitive customer information. It is important that detailed error messages be visible only to those who are authorized to view them; that general users receive only generalized acknowledgment that errors have occurred; and that these generalized messages appear only when relevant to the user's task. For example, a message along the lines of, "An error has occurred. Unable to save your changes. If this problem persists, contact the help desk" would be relevant. A message such as "Warning: your transaction generated a large number of page splits" would likely not be relevant. Administrative users authorized to review detailed error messages typically are the ISSO, ISSM, SA, and DBA. Other individuals or roles may be specified according to organization-specific needs, with appropriate approval. This calls for inspection of application source code, which will require collaboration with the application developers. It is recognized that in many cases, the database administrator (DBA) is organizationally separate from the application developers, and may have limited, if any, access to source code. Nevertheless, protections of this type are so important to the secure operation of databases that they must not be ignored. At a minimum, the DBA must attempt to obtain assurances from the development organization that this issue has been addressed, and must document what has been discovered.

STIG	Date
EnterpriseDB Postgres Advanced Server (EPAS) Security Technical Implementation Guide	2023-11-20

Details

Check Text ( C-63006r938852_chk )
Check the EDB Postgres Advanced Server settings and custom database code to determine if detailed error messages are ever displayed to unauthorized individuals. To check the level of detail for errors exposed to clients, run the following as the "enterprisedb" operating system user: > psql edb -c "SHOW client_min_messages" If client_min_messages is not set to ERROR, this is a finding. If detailed error messages for any custom code are displayed to users not authorized to view them, this is a finding. Additionally, logs may contain detailed information and should only be accessible by the database owner. As the "enterprisedb" operating system user, verify that the log_file_mode parameter is set to 0600: > psql edb -c "SHOW log_file_mode" If log_file_mode is not set to 0600, this is a finding. If the EDB Postgres Advanced Server is configured to use syslog for logging, consult organization location and permissions for syslog log files. If the logs are not owned by root or have permissions that are not 0600, this is a finding.

Check Text ( C-63006r938852_chk )

Check the EDB Postgres Advanced Server settings and custom database code to determine if detailed error messages are ever displayed to unauthorized individuals.

To check the level of detail for errors exposed to clients, run the following as the "enterprisedb" operating system user:

> psql edb -c "SHOW client_min_messages"

If client_min_messages is not set to ERROR, this is a finding.

If detailed error messages for any custom code are displayed to users not authorized to view them, this is a finding.

Additionally, logs may contain detailed information and should only be accessible by the database owner.

As the "enterprisedb" operating system user, verify that the log_file_mode parameter is set to 0600:

> psql edb -c "SHOW log_file_mode"

If log_file_mode is not set to 0600, this is a finding.

If the EDB Postgres Advanced Server is configured to use syslog for logging, consult organization location and permissions for syslog log files. If the logs are not owned by root or have permissions that are not 0600, this is a finding.

Fix Text (F-62915r938853_fix)
Set the client_min_messages parameter to "ERROR". As the "enterprisedb" operating system user: > psql edb -c "ALTER SYSTEM SET client_min_messages='ERROR'" > psql edb -c "SELECT pg_reload_conf()" > psql edb -c "SHOW client_min_messages" Set the log_file_mode to 0600. As the "enterprisedb" operating system user: > psql edb -c "ALTER SYSTEM SET log_file_mode='0600'" > psql edb -c "SELECT pg_reload_conf()" > psql edb -c "SHOW log_file_mode"

Fix Text (F-62915r938853_fix)

Set the client_min_messages parameter to "ERROR". As the "enterprisedb" operating system user:

> psql edb -c "ALTER SYSTEM SET client_min_messages='ERROR'"
> psql edb -c "SELECT pg_reload_conf()"
> psql edb -c "SHOW client_min_messages"

Set the log_file_mode to 0600. As the "enterprisedb" operating system user:

> psql edb -c "ALTER SYSTEM SET log_file_mode='0600'"
> psql edb -c "SELECT pg_reload_conf()"
> psql edb -c "SHOW log_file_mode"